\documentclass{article}
\usepackage[pdftex]{color,graphicx} 
\usepackage[bookmarks=true,colorlinks]{hyperref}


\title{Conceptual design for the DGB stanalone GUI}
\author{Benjamin Nortier}

\begin{document}

\maketitle

\newpage

\tableofcontents

\section{Introduction}

Models within the DGB can be very complex, and users need to be removed from this complexity. The best way to do this is to present a diagrammatic graph-like interface to the DGB, which is the model in which most users design and  construct their models and queries.

The standalone GUI for the DGB should satisfy three main requirements:

\begin{enumerate}
\item Creating queries. The GUI must enable the user to construct queries graphically, without knowledge of the underlying query language.
\item Browsing results. The user must be able to examine the sets and graphs that result from queries graphically, with varying levels of detail.
\item Discovering the DGB. The GUI must enable exploration of the system so users can expand their knowledge and use of the system.
\item Communication. The GUI must enable the user to communicate their models better to other people. 
\end{enumerate}

It is essential that the system integrates all three these functions elagantly. The user must be free to construct and explore queries iteratively, which requires that query results can be re-used in new queries. The interface in which the DGB is explored should also be used to construct queries.

\section{High-level functional requirements}

\subsection{Introduction}

The functionality of the system shares many features of applications used for constructing diagrams such as \href{http://www.inkscape.org}{InkScape}, \href{http://www.omnigroup.com/applications/omnigraffle/}{OmniGraffle} and \href{http://office.microsoft.com/en-us/visio/default.aspx}{Visio}. In essence, these application uses shapes and connections between shapes to express a diagram. The GUI will represent a similar interface, using different shapes to represent layers, concepts and relations and edges to represent arc bewteen them. Dragging items around the workspace, selection, copy \& paste grouping etc. are all familiar concepts, and the GUI will re-use these well-known interactions to make the system easy to learn.

\subsection{Conceptual designs and prototypes}

\subsubsection{Canvas}

The standalone GUI application will have an MDI (multiple document interface), and each document will consist of a canvas, and multiple canvases can be worked with concurrently. Queries are constructed on the canvas, and it is also used to examine results and explore the system. Items can be dragged onto the canvas to create new queries, and arcs can be created between items. 

\subsubsection{Conceptron items}

Conceptron items are items that can represent a concept, relation or layer. Each conceptron item also represents a unique query string in the DGB query language. The query can also be submitted to the DGB, and the result displayed when the query has completd. An item is a 1-to-1 representation of a query, with added data such as position on the canvas.

Each item must represent the following:

\begin{enumerate}
\item The type of the item (a set, graph, boolean and, path etc)
\item The name of the item. Items can be renamed to make them more understandable to the user, instead of just seeing a ``AND'' or ``go\_term''. I.e. each query will have a name assigned by the user. Having a name means the items can be labelled in a more understandable way, e.g. ``Go term for A and B'' instead of ``go\_term.id[GO:0000001] OR go\_term.id[GO:0000002]''.
\item The child items, e.g. the items in a boolean ``OR''.
\item An indication of whether the query has been executed, and whether the result is available.
\item The result size.
\item The actual result, which is also an item.
\item Whether the result is current. Because querying will be asynchronous, the item can still be edited whilst a query is being processed, so there must be an indication of whether the result is correctly associated with the query.
\end{enumerate}

\begin{figure} 
\centering 
\includegraphics[scale=2.0]{conceptron_item_expanded_annotated.png} 
\caption{Conceptron item prototype (expanded)}
\label{fig:conceptron_item_expanded_annotated}
\end{figure}

\autoref{fig:conceptron_item_expanded_annotated} shows an item prototype. The children and results views can be expanded/collapsed. A method to indicated whether a query has been executed and the size of the query are not shown. The type of the item is indicated by an icon (in this case, the intersection item has an icon indicating the interseciton of two circles). The item type for the children and the result indicated that they are sets. 

\subsubsection{Expand/Collapse}

Items can be expanded and collapsed as required by the user. Each item will have two main options for expanding/collapsing, i.e. to view the child items or viewing query results. GUI elements that enable expanding/collapsing will only be visible on hover (see \autoref{sec:hover}). Upon expanding/collapsing the layout of the canvas should adapt to cater for the new item sizes whilst still mainting arc connectivity.

\begin{figure} 
\centering 
\includegraphics[scale=2.0]{expand.png} 
\caption{Expanding an item show children.} 
\label{fig:expand_children}
\end{figure}

\autoref{fig:expand_children} shows the expand/collapse concept. Clicking on the children icon expands the item to show the children of the intersection (a boolean ``AND''). The same button is clicked on again to collapse the child view. The transition is animated. Zooming can also be used to make better use of the canvas.

\subsubsection{Arcs}

Arcs (edges in a diagram application) can be created bewteen items. These represent arcs in the DGB. \autoref{fig:human_mouse_relation} shows this concept. Arcs will be selectable, copy-and-pastable etc.

\begin{figure} 
\centering 
\includegraphics[scale=2.0]{human_mouse_relation.png} 
\caption{Example arcs in a relationships between human and mouse genes}
\label{fig:human_mouse_relation}
\end{figure}

\subsubsection{Creating a query}

A query is constructed by iteratively narrowing the search space. For example, the user specifies which layers to use by dragging the layers onto the canvas (concept and relation types can also be used directly). The system can flesh out the layers and show which concept types are available within the layer upon request. The user can delve deeper into the layers or decide which concept and relation types to explore/use in the query. The user can for example select some concept types, and then ask that relation types that exist between the concept types be inserted by the system. (If the types are known, this step can be skipped and the arcs created directly).

The user then narrows down the types by specifying attributes on concept types to obtain sets of instances, and these sets are used on more advanced queries. A canvas can be saved for re-use when constructing queries within the same model. At any point the selection of items can be copied and pasted onto the same canvas or a new canvas to start construcitng a new query.

Boolean operation can be applied to selected items to construct higher-level sets and graphs. A toolbar will provide often-used operations such and AND, OR and NOT operations on the selected items.

\subsubsection{Results browsing and re-use}

Results will be displayed on the same generic way as other items. This will enable re-use of results in the construction of new queries, without suffering the problem of executing the query again. This is especially useful if queries take significant time to process. 

\begin{figure} 
\centering 
\includegraphics[scale=1.0]{drag_results.png} 
\caption{Dragging results to create a new item}
\label{fig:drag_results}
\end{figure}

To use the query results in a new query, the results item is simply dragged onto empty space on the canvas (See \autoref{fig:drag_results}).

\subsubsection{Asynchronous query execution}

Queries are executed asynchronously and the items are populated with the results when the results are available. The query will be identified by the query string, so it can also be re-used in other items that represent the same query. The item will e updated to show that a result has been obtained, and other notification methods can also be used to alert the user of a completed query.

\section{Design guidelines}

\subsection{Re-use}

As much as possible generic concepts (not in the DGB sense) should be used. This will make the application more intuitive, consistent and easier to learn. E.g. the methods the user is used to when dealing with concepts (in the DGB sense), should be applied to other kinds of sets and vice versa. Interactions such as operations on selections, as opposed to selecting items during a state-driven operation should be used where possible.

\subsection{Use of context}

Context should be used as much as possible for re-using keyboard shortcuts. The currently active selection determines the context of keyboard shortcuts.

\subsection{Optimisation}

The application should be able to optimize queries to maximize system performance. As an example, if the user creates an ``AND'' between  the entire set of Medline citations and those having a title containing ``Cancer'', the query should actually only be the set of the citations containing ``Cancer''. If this is implemented in the backend this will not be necessary.

\subsection{Selection}

Selection will be indicated with a clearly visible halo in a colour that contrasts well with the background colour. Where possible operation are performed on the selected items.


\subsection{Dynamic adaptive graph layout}

The GUI will make extensive use of dynamic adaptable graph layouts. When items are added/removed from graphs, layouts must be re-evaluated and the new layout must be trasitioned to via animation. See \href{http://prefuse.org/media/prefuse.wmv}{prefuse} for some ideas regarding dynamic graph layouts and what they can add to the user experience.

\subsection{Seperation of type and name}

The user will be able to name items and these names will be the main display element for items that are collapsed. Default names will be assigned according to their type (i.e. a set, graph or boolean operations), but are not descriptive enough. Well though out names assigned by a user will improve understanding of the model/query when items are collapsed.

\subsection{Draggging and dropping}

Dragging and dropping will be used extensively. Items will be dragged onto the canvas to create them. Item can be dragged around the canvas for better positioning/layout.

\subsection{Copy and paste}

The user will be able to copy and past and selected item(s).

\subsection{Undo/Redo}

A full undo/redo system must be implemented.

\subsection{Icons}

Wherever possible, icons should be used to represent concepts. Hoever, these icons must be clear to understand, and if there's ambiguity or doubt, a textual representaiton should be used. Even though a textual reprentation consumes more space on the screen, clarity to user takes precedence.

\subsection{Look \& Feel}

\subsubsection{Shadows}

Shadows can be applied to items to add to the user experience. They can be disabled by the user for better performance.

\subsubsection{Anti-aliasing}

Anti-aliasing must be enabled when available. The contribution to the look\&feel of the application is significant and must be used.

\subsubsection{Alpha-blending}

Extensive use of alphablending will be used. Modern graphicss cards and windowing systems suffer very little performance penalties for alpha-blending.

\subsection{Hover}
\label{sec:hover}
When hovering over items on the canvas, extra functions that clutter the view will be revealed. These can include expanding the child and results view. Elements that contain information in themselves (e.g if the button that expands the item to show the result set also has an indicator of a result) should not be hidden.

\section{Use cases}

\subsection{Example query 1}

Example query: Find all human genes that are annotated with the GO terms GO:0000001 or GO:0000002.

\begin{itemize}
\item The user chooses the layers of interest. (Hypothetically, human genes, mouse genes and the GO ontology are in 3 separate layers). The user drags those three layers onto the canvas. (Term for ``canvas''?). 
\item (Optional?) The layers are expanded to show which concpet types reside within the layer.
\item The user is selects the ``Gene'' concept type from the ``Human genes'' layer, the ``Gene'' concept type from the ``Mouse genes'' layer, and the ``go\_term'' concept type from the ``GO'' layer.
\item The user chooses to add the relation types between the selected doncept types and the system insrtes the relation archetypes between the concept types.
\item The user removes the unwanted relation types.
\end{itemize}

Essentially these steps constitute exploration/navigation of the data within the DGB. The use has an idea of what is required, but isn't sure of the exact concept type and relation types names that are neede for the query. The template for the query has been created, and the query can now be constructed by specifying the two specific GO terms to query.

\begin{itemize}
\item The ``go\_term'' concept type is selected.
\item The use choose to refine by only choosing certain concept instances, i.e. by specifying only those with the symbol equal to ``GO:0000001'' or ``GO:0000002''. The instance set is specified by performing an ``OR'' operation on the two selected entities.
\item At this point the user must specify what the result is that's required, which in this case is the set of gene instances in the human gene layer that are connected to the instances of the ``annotated'' relation that are connected to the instances of the ``go\_term'' concept type. If possible the system should know to follow the arcs down to where sets can be constructed (in this example down to the ``OR'' set of the two go terms, then get the relation instances then get the instances of the gene concept that are connected to the relation instances.
\end{itemize}

\subsection{Example query 2}

Find all Medline citations with the word ``cancer'' in the abstract that mention genes A,B or C.

This case shows the required flexibility of the system. The user can ``OR'' all the gene concepts with the required symbols. From there get the instances of the ``Mentions'' relation that connect to the set of genes, and from there the ``Citation'' concepts. Alternatively, the ``Mention'' instances for each of the gene instances can be retrieved, and those instances ``OR''ed together to form the set that is use to get the ``Citation'' instances. Here we're faced with a problem however, the the ``Citation'' concepts also have a filter, i.e. only retrieve those with the word ``Cancer'' in the abstract. How to handle this isn't determined yet.


\end{document}
